Untitled Document

S.M. Bellovin* smb@ulysses.att.com

AT&T Bell Laboratories Murray Hill, New Jersey 07974

ABSTRACT

The TCP/IP protocol suite, which is very widely used today, was
developed under the sponsorship of the Department of Defense. Despite that,
there are a number of serious security flaws inherent in the protocols,
regardless of the correctness of any implementations. We describe a variety
of attacks based on these flaws, including sequence number spoofing, routing
attacks, source address spoofing, and authentication attacks. We also
present defenses against these attacks, and conclude with a discussion of
broad-spectrum defenses such as encryption.

1. INTRODUCTION

The TCP/IP protocol suite [1][2] , which is very widely used today,
was developed under the sponsorship of the Department of Defense. Despite
that, there are a number of serious security flaws inherent in the
protocols. Some of these flaws exist because hosts rely on IP source
address for authentication; the Berkeley ``r-utilities'' [3] are a notable
example. Others exist because network control mechanisms, and in particular
routing protocols, have minimal or non-existent authentication.

When describing such attacks, our basic assumption is that the
attacker has more or less complete control over some machine connected to
the Internet. This may be due to flaws in that machine's own protection
mechanisms, or it may be because that machine is a microcomputer, and
inherently unprotected. Indeed, the attacker may even be a rogue system
administrator.

1.1 Exclusions

We are not concerned with flaws in particular implementations of
the protocols, such as those used by the Internet ``worm'' [4][5][6] .
Rather, we discuss generic problems with the protocols themselves. As will
be seen, careful implementation techniques can alleviate or prevent some of
these problems. Some of the protocols we discuss are derived from
Berkeley's version of the UNIX (R) system; others are generic Internet
protocols.

We are also not concerned with classic network attacks, such as
physical eavesdropping, or altered or injected messages. We discuss such
problems only in so far as they are facilitated or possible because of
protocol problems.

For the most part, there is no discussion here of vendor-specific
protocols. We do discuss some problems with Berkeley's protocols, since
these have become de facto standards for many vendors, and not just for UNIX
systems.

2. TCP SEQUENCE NUMBER PREDICTION

One of the more fascinating security holes was first described by
Morris [7] . Briefly, he used TCP sequence number prediction to construct a
TCP packet sequence without ever receiving any responses from the server.
This allowed him to spoof a trusted host on a local network.

__________________

* Author's address: Room 3C-536B AT&T Bell Laboratories, 600 Mountain
Avenue, Murray Hill, New Jersey 07974.

Reprinted from Computer Communication Review, Vol. 19, No. 2, pp. 32-48,
April 1989.

- 2 -

The normal TCP connection establishment sequence involves a 3-way handshake.
The client selects and transmits an initial sequence number ISN C , the
server acknowledges it and sends its own sequence number ISN S , and the
client acknowledges that. Following those three messages, data transmission
may take place. The exchange may be shown schematically as follows:

C*S:SYN(ISN C ) S*C:SYN(ISN S ) ,ACK(ISN C ) C*S:ACK(ISN S ) C*S:data and /
or S*C:data

That is, for a conversation to take place, C must first hear ISN S , a more
or less random number.

Suppose, though, that there was a way for an intruder X to predict ISN S .
In that case, it could send the following sequence to impersonate trusted
host T:

X*S:SYN(ISN X ) ,SRC = T S*T:SYN(ISN S ) ,ACK(ISN X ) X*S:ACK(ISN S ) ,SRC =
T X*S:ACK(ISN S ) ,SRC = T,nasty - data

Even though the message S*T does not go to X, X was able to know its
contents, and hence could send data. If X were to perform this attack on a
connection that allows command execution (i.e., the Berkeley rsh server),
malicious commands could be executed.

How, then, to predict the random ISN? In Berkeley systems, the
initial sequence number variable is incremented by a constant amount once
per second, and by half that amount each time a connection is initiated.
Thus, if one initiates a legitimate connection and observes the ISN S used,
one can calculate, with a high degree of confidence, ISN S * used on the
next connection attempt.

Morris points out that the reply message

S*T:SYN(ISN S ) ,ACK(ISN X )

does not in fact vanish down a black hole; rather, the real host T
will receive it and attempt to reset the connection. This is not a serious
obstacle. Morris found that by impersonating a server port on T, and by
flooding that port with apparent connection requests, he could generate
queue overflows that would make it likely that the S*T message would be
lost. Alternatively, one could wait until T was down for routine
maintenance or a reboot.

A variant on this TCP sequence number attack, not described by
Morris, exploits the netstat [8] service. In this attack, the intruder
impersonates a host that is down. If netstat is available on the target
host, it may supply the necessary sequence number information on another
port; this eliminates all need to guess 1 .

Defenses Obviously, the key to this attack is the relatively coarse
rate of change of the initial sequence number variable on Berkeley systems.
The TCP specification requires that this variable be incremented
approximately 250,000 times per second; Berkeley is using a much slower
rate. However, the critical factor is the granularity, not the average
rate. The change from an increment of 128 per second in 4.2BSD to 125,000
per second in 4.3BSD is meaningless, even though the latter is within a
factor of two of the specified rate.

__________________

1. The netstat protocol is obsolete, but is still present on some Internet
hosts. Security concerns were not behind its elimination.

- 3 -

Let us consider whether a counter that operated at a true 250,000
hz rate would help. For simplicity's sake, we will ignore the problem of
other connections occurring, and only consider the fixed rate of change of
this counter.

To learn a current sequence number, one must send a SYN packet, and receive
a response, as follows:

X*S: SYN(ISN X ) S*X: SYN(ISN S ) ,ACK(ISN X ) (1)

The first spoof packet, which triggers generation of the next
sequence number, can immediately follow the server's response to the probe
packet:

X*S: SYN(ISN X ) ,SRC = T (2)

The sequence number ISN S used in the response

S*T: SYN(ISN S ) ,ACK(ISN X )

is uniquely determined by the time between the origination of
message (1) and the receipt at the server of message (1). But this number
is precisely the round-trip time between X and S. Thus, if the spoofer can
accurately measure (and predict) that time, even a 4 u-second clock will not
defeat this attack.

How accurately can the trip time be measured? If we assume that
stability is good, we can probably bound it within 10 milliseconds or so.
Clearly, the Internet does not exhibit such stability over the long-term [9]
, but it is often good enough over the short term. 2 There is thus an
uncertainty of 2500 in the possible value for ISN S . If each trial takes 5
seconds, to allow time to re-measure the round-trip time, an intruder would
have a reasonable likelihood of succeeding in 7500 seconds, and a
near-certainty within a day. More predictable (i.e., higher quality)
networks, or more accurate measurements, would improve the odds even further
in the intruder's favor. Clearly, simply following the letter of the TCP
specification is not good enough.

We have thus far tacitly assumed that no processing takes places
on the target host. In fact, some processing does take place when a new
request comes in; the amount of variability in this processing is critical.
On a 6 MIPS machine, one tick -- 4 u-seconds -- is about 25 instructions.
There is thus considerable sensitivity to the exact instruction path
followed. High-priority interrupts, or a slightly different TCB allocation
sequence, will have a comparatively large effect on the actual value of the
next sequence number. This randomizing effect is of considerable advantage
to the target. It should be noted, though, that faster machines are more
vulnerable to this attack, since the variability of the instruction path
will take less real time, and hence affect the increment less. And of
course, CPU speeds are increasing rapidly.

This suggests another solution to sequence number attacks:
randomizing the increment. Care must be taken to use sufficient bits; if,
say, only the low-order 8 bits were picked randomly, and the granularity of
the increment was coarse, the intruder's work factor is only multiplied by
256. A combination of a fine-granularity increment and a small random
number generator, or just a 32-bit generator, is better. Note, though, that
many pseudo-random number generators are easily invertible [10] . In fact,
given that most such generators work via feedback of their output, the enemy
could simply compute the next ``random'' number to be picked. Some hybrid
techniques have promise -- using a 32-bit generator, for example, but only
emitting 16 bits of it -- but brute-force attacks could succeed at
determining the seed. One would need at least 16 bits of random data in each
increment, and perhaps more, to defeat probes from the network, but that
might leave too few bits to guard against a search for the seed. More
research or simulations are needed to determine the proper parameters.

__________________

2. At the moment, the Internet may not have such stability even over the
short-term, especially on long-haul connections. It is not comforting to
know that the security of a network relies on its low quality of service.

- 4 -

Rather than go to such lengths, it is simpler to use a
cryptographic algorithm (or device) for ISN S generation. The Data
Encryption Standard [11] (DES) in electronic codebook mode [12] is an
attractive choice as the ISN S source, with a simple counter as input.
Alternatively, DES could be used in output feedback mode without an
additional counter. Either way, great care must be taken to select the key
used. The time-of-day at boot time is not adequate; sufficiently good
information about reboot times is often available to an intruder, thereby
permitting a brute-force attack. If, however, the reboot time is encrypted
with a per-host secret key, the generator cannot be cracked with any
reasonable effort.

Performance of the initial sequence number generator is not a
problem. New sequence numbers are needed only once per connection, and even
a software implementation of DES will suffice. Encryption times of 2.3
milliseconds on a 1 MIPS processor have been reported [13] .

An additional defense involves good logging and alerting mechanisms.
Measurements of the round-trip time -- essential for attacking RFC-compliant
hosts -- would most likely be carried out using ICMP Ping messages; a
``transponder'' function could log excessive ping requests. Other, perhaps
more applicable, timing measurement techniques would involve attempted TCP
connections; these connections are conspicuously short-lived, and may not
even complete SYN processing. Similarly, spoofing an active host will
eventually generate unusual types of RST packets; these should not occur
often, and should be logged.

3. THE JOY OF ROUTING

Abuse of the routing mechanisms and protocols is probably the
simplest protocol-based attack available. There are a variety of ways to do
this, depending on the exact routing protocols used. Some of these attacks
succeed only if the remote host does source address-based authentication;
others can be used for more powerful attacks.

A number of the attacks described below can also be used to
accomplish denial of service by confusing the routing tables on a host or
gateway. The details are straight-forward corollaries of the penetration
mechanisms, and will not be described further.

3.1 Source Routing

If available, the easiest mechanism to abuse is IP source routing.
Assume that the target host uses the reverse of the source route provided in
a TCP open request for return traffic. Such behavior is utterly reasonable;
if the originator of the connection wishes to specify a particular path for
some reason -- say, because the automatic route is dead -- replies may not
reach the originator if a different path is followed.

The attacker can then pick any IP source address desired,
including that of a trusted machine on the target's local network. Any
facilities available to such machines become available to the attacker.

Defenses It is rather hard to defend against this sort of attack.
The best idea would be for the gateways into the local net to reject
external packets that claim to be from the local net. This is less
practical than it might seem since some Ethernet 3 network adapters receive
their own transmissions, and this feature is relied upon by some
higher-level protocols. Furthermore, this solution fails completely if an
organization has two trusted networks connected via a multi-organization
backbone. Other users on the backbone may not be trustable to the same
extent that local users are presumed to be, or perhaps their vulnerability
to outside attack is higher. Arguably, such topologies should be avoided in
any event.

A simpler method might be to reject pre-authorized connections if
source routing information was present. This presumes that there are few
legitimate reasons for using this IP option, especially for

__________________

3. Ethernet is a registered trademark of Xerox Corporation.

- 5 -

relatively normal operations. A variation on this defense would be
to analyze the source route and accept it if only trusted gateways were
listed; that way, the final gateway could be counted on to deliver the
packet only to the true destination host. The complexity of this idea is
probably not worthwhile.

Some protocols (i.e., Berkeley's rlogin and rsh) permit ordinary users to
extend trust to remote host/user combinations. In that case, individual
users, rather than an entire system, may be targeted by source routing
attacks. 4 Suspicious gateways [14] will not help here, as the host being
spoofed may not be within the security domain protected by the gateways.

3.2 Routing Information Protocol Attacks

The Routing Information Protocol [15] (RIP) is used to propagate
routing information on local networks, especially broadcast media.
Typically, the information received is unchecked. This allows an intruder
to send bogus routing information to a target host, and to each of the
gateways along the way, to impersonate a particular host. The most likely
attack of this sort would be to claim a route to a particular unused host,
rather than to a network; this would cause all packets destined for that
host to be sent to the intruder's machine. (Diverting packets for an entire
network might be too noticeable; impersonating an idle work-station is
comparatively risk-free.) Once this is done, protocols that rely on
address-based authentication are effectively compromised.

This attack can yield more subtle, and more serious, benefits to
the attacker as well. Assume that the attacker claims a route to an active
host or workstation instead. All packets for that host will be routed to
the intruder's machine for inspection and possible alteration. They are
then resent, using IP source address routing, to the intended destination.
An outsider may thus capture passwords and other sensitive data. This mode
of attack is unique in that it affects outbound calls as well; thus, a user
calling out from the targeted host can be tricked into divulging a password.
Most of the earlier attacks discussed are used to forge a source address;
this one is focused on the destination address.

Defenses A RIP attack is somewhat easier to defend against than the
source-routing attacks, though some defenses are similar. A paranoid
gateway -- one that filters packets based on source or destination address
-- will block any form of host-spoofing (including TCP sequence number
attacks), since the offending packets can never make it through. But there
are other ways to deal with RIP problems.

One defense is for RIP to be more skeptical about the routes it
accepts. In most environments, there is no good reason to accept new routes
to your own local networks. A router that makes this check can easily
detect intrusion attempts. Unfortunately, some implementations rely on
hearing their own broadcasts to retain their knowledge of directly-attached
networks. The idea, presumably, is that they can use other networks to
route around local outages. While fault-tolerance is in general a good
idea, the actual utility of this technique is low in many environments
compared with the risks.

It would be useful to be able to authenticate RIP packets; in
the absence of inexpensive public-key signature schemes, this is difficult
for a broadcast protocol. Even if it were done, its utility is limited; a
receiver can only authenticate the immediate sender, which in turn may have
been deceived by gateways further upstream.

Even if the local routers don't implement defense mechanisms, RIP
attacks carry another risk: the bogus routing entries are visible over a
wide area. Any router (as opposed to host) that receives such data will
rebroadcast it; a suspicious administrator almost anywhere on the local
collection of networks could notice the anomaly. Good log generation would
help, but it is hard to distinguish a genuine intrusion from the routing
instability that can accompany a gateway crash.

__________________

4. Permitting ordinary users to extend trust is probably wrong in
any event, regardless of abuse of the protocols. But such concerns are
beyond the scope of this paper.

- 6 -

3.3 Exterior Gateway Protocol

The Exterior Gateway Protocol (EGP) [16] is intended for communications
between the core gateways and so-called exterior gateways. An exterior
gateway, after going through a neighbor acquisition protocol, is
periodically polled by the core; it responds with information about the
networks it serves. These networks must all be part of its autonomous
system. Similarly, the gateway periodically requests routing information
from the core gateway. Data is not normally sent except in response to a
poll; furthermore, since each poll carries a sequence number that must be
echoed by the response, it is rather difficult for an intruder to inject a
false route update. Exterior gateways are allowed to send exactly one
spontaneous update between any two polls; this, too, must carry the sequence
number of the last poll received. It is thus comparatively difficult to
interfere in an on-going EGP conversation.

One possible attack would be to impersonate a second exterior
gateway for the same autonomous system. This may not succeed, as the core
gateways could be equipped with a list of legitimate gateways to each
autonomous system. Such checks are not currently done, however. Even if
they were, they could be authenticated only by source IP address.

A more powerful attack would be to claim reachability for some
network where the real gateway is down. That is, if gateway G normally
handles traffic for network N, and G is down, gateway G*could advertise a
route to that network. This would allow password capture by assorted
mechanisms. The main defense against this attack is topological (and quite
restrictive): exterior gateways must be on the same network as the core;
thus, the intruder would need to subvert not just any host, but an existing
gateway or host that is directly on the main net.

A sequence number attack, similar to those used against TCP, might
be attempted; the difficulty here is in predicting what numbers the core
gateway is using. In TCP, one can establish arbitrary connections to probe
for information; in EGP, only a few hosts may speak to the core. (More
accurately, the core could only speak to a few particular hosts, though as
noted such checks are not currently implemented.) It may thus be hard to get
the raw data needed for such an attack.

3.4 The Internet Control Message Protocol

The Internet Control Message Protocol (ICMP) [17] is the basic network
management tool of the TCP/IP protocol suite. It would seem to carry a rich
potential for abuse. Surprisingly, ICMP attacks are rather difficult;
still, there are often holes that may be exploited.

The first, and most obvious target, is the ICMP Redirect message; it is used
by gateways to advise hosts of better routes. As such it can often be
abused in the same way that RIP can be. The complication is that a Redirect
message must be tied to a particular, existing connection; it cannot be used
to make an unsolicited change to the host's routing tables. Furthermore,
Redirects are only applicable within a limited topology; they may be sent
only from the first gateway along the path to the originating host. A later
gateway may not advise that host, nor may it use ICMP Redirect to control
other gateways.

Suppose, though, that an intruder has penetrated a secondary
gateway available to a target host, but not the primary one. (It may
suffice to penetrate an ordinary host on the target's local network, and
have it claim to be a gateway.) Assume further that the intruder wishes to
set up a false route to trusted host T through that compromised secondary
gateway. The following sequence may then be followed. Send a false TCP
open packet to the target host, claiming to be from T. The target will
respond with its own open packet, routing it through the secure primary
gateway. While this is in transit, a false Redirect may be sent, claiming
to be from the primary gateway, and referring to the bogus connection. This
packet will appear to be a legitimate control message; hence the routing
change it contains will be accepted. If the target host makes this change
to its global routing tables, rather than just to the per connection cached
route, the intruder may proceed with spoofing host T.

Some hosts do not perform enough validity checks on ICMP Redirect
messages; in such cases, the impact of this attack becomes similar to
RIP-based attacks.

ICMP may also be used for targeted denial of service attacks.
Several of its messages, such as Destination Unreachable and Time to Live
Exceeded, may be used to reset existing connections. If the

- 7 -

intruder knows the local and remote port numbers of a TCP
connection, an ICMP packet aimed at that connection may be forged 5 . Such
information is sometimes available through the netstat service.

A more global denial of service attack can be launched by sending
a fraudulent Subnet Mask Reply message. Some hosts will accept any such
message, whether they have sent a query or not; a false one could
effectively block all communications with the target host.

Defenses Most ICMP attacks are easy to defend against with just a
modicum of paranoia. If a host is careful about checking that a message
really does refer to a particular connection, most such attacks will not
succeed. In the case of TCP, this includes verifying that the ICMP packet
contains a plausible sequence number in the returned-packet portion. These
checks are less applicable to UDP, though.

A defense against Redirect attacks merits additional attention,
since such attacks can be more serious. Probably, the best option is to
restrict route changes to the specified connection; the global routing table
should not be modified in response to ICMP Redirect messages 6 .

Finally, it is worth considering whether ICMP Redirects are even
useful in today's environment. They are only usable on local networks with
more than one gateway to the outside world. But it is comparatively easy to
maintain complete and correct local routing information. Redirect messages
would be most useful from the core gateways to local exterior gateways, as
that would allow such local gateways to have less than complete knowledge of
the Internet; this use is disallowed, however.

Subnet Mask attacks can be blocked if the Reply packet is honored
only at the appropriate time. In general, a host wants to see such a
message only at boot time, and only if it had issued a query; a stale reply,
or an unsolicited reply, should be rejected out of hand. There is little
defense against a forged reply to a genuine Subnet Mask query, as a host
that has sent such a query typically has few resources with which to
validate the response. If the genuine response is not blocked by the
intruder, though, the target will receive multiple replies; a check to
ensure that all replies agree would guard against administrative errors as
well.

4. THE ``AUTHENTICATION'' SERVER

As an alternative to address-based authentication, some
implementations use the Authentication Server [18] . A server that wishes
to know the identity of its client may contact the client host's
Authentication Server 7 , and ask it for information about the user owning a
particular connection. This method is inherently more secure than simple
address-based authentication, as it uses a second TCP connection not under
control of the attacker. It thus can defeat sequence number attacks and
source routing attacks. There are certain risks, however.

The first, and most obvious, is that not all hosts are competent
to run authentication servers. If the client host is not secure, it does
not matter who the user is claimed to be; the answer cannot be trusted.
Second, the authentication message itself can be compromised by routing
table attacks. If RIP has been used to alter the target's idea of how to
reach some host, the authentication query will rely on the same altered
routing data. Finally, if the target host is down, a variant on the TCP
sequence number attack may be used; after the server sends out a TCP open
request to the presumed authentication server, the attacker can complete the
open sequence and send a false reply. If the target runs a netstat server,
this is even easier; as noted, netstat will often supply the necessary
sequence numbers with no need to guess.

__________________

5. In fact, such programs are available today; they are used as
administrative tools to reset hung TCP connections.

6. This has other benefits as well, especially in environments where
ICMP-initiated route changes are not timed out. The author has seen
situations where RIP instability following a gateway crash has led to
erroneous ICMP Redirect messages. These had the effect of permanently
corrupting the routing tables on other hosts.

7. The Internet Activities Board does not currently recommend the
Authentication Server for implementation [19] . However, the decision was
not made because of security problems [5] .

- 8 -

A less-obvious risk is that a fake authentication server can always reply
``no''. This constitutes a denial of service attack.

Defenses A server that wishes to rely on another host's idea of a
user should use a more secure means of validation, such as the
Needham-Schroeder algorithm [20][21][22] . TCP by itself is inadequate.

5. HERE BE DRAGONS

Some protocols, while not inherently flawed, are nevertheless susceptible to
abuse. A wise implementor would do well to take these problems into account
when providing the service.

5.1 The ``Finger'' Service

Many systems implement a finger service [23] . This server will
display useful information about users, such as their full names, phone
numbers, office numbers, etc. Unfortunately, such data provides useful
grist for the mill of a password cracker. [24] By running such a service, a
system administrator is giving away this data.

5.2 Electronic Mail

Electronic mail is probably the most valuable service on the Internet.
Nevertheless, it is quite vulnerable to misuse. As normally implemented
[25][26] , the mail server provides no authentication mechanisms. This
leaves the door wide open to faked messages. RFC 822 does support an
Encrypted header line, but this is not widely used. (However, see RFC 1040
[27] for a discussion of a proposed new encryption standard for electronic
mail.)

5.2.1 The Post Office Protocol

The The Post Office Protocol (POP) [28] allows a remote user to
retrieve mail stored on a central server machine. Authentication is by
means of a single command containing both the user name and the password.
However, combining the two on a single command mandates the use of
conventional passwords. And such passwords are becoming less popular; they
are too vulnerable to wire-tappers, intentional or accidental disclosure,
etc.

As an alternative, many sites are adopting ``one-time passwords'' 8
. With one-time passwords, the host and some device available to the user
share a cryptographic key. The host issues a random challenge; both sides
encrypt this number, and the user transmits it back to the host. Since the
challenge is random, the reply is unique to that session, thereby defeating
eavesdroppers. And since the user does not know the key -- it is
irretrievably stored in the device -- the password cannot be given away
without depriving the user of the ability to log in.

The newest version of POP [30] has split the user name and
password into two commands, which is useful. However, it also defines an
optional mechanism for preauthenticated connections, typically using
Berkeley's mechanisms. Commendably, the security risks of this variant are
mentioned explicitly in the document.

5.2.2 PCMAIL

The PCMAIL protocol [31] uses authentication mechanisms similar to
those in POP2. In one major respect, PCMAIL is more dangerous: it supports
a password-change command. This request requires that both the old and new
passwords be transmitted unencrypted.

__________________

8. One-time passwords were apparently first used for military IFF
(Identification Friend or Foe) systems [29] .

- 9 -

5.3 The Domain Name System

The Domain Name System (DNS) [32][33] provides for a distributed
database mapping host names to IP addresses. An intruder who interferes
with the proper operation of the DNS can mount a variety of attacks,
including denial of service and password collection. There are a number of
vulnerabilities.

In some resolver implementations, it is possible to mount a
sequence number attack against a particular user. When the target user
attempts to connect to a remote machine, an attacker can generate a domain
server response to the target's query. This requires knowing both the UDP
port used by the client's resolver and the DNS sequence number used for the
query. The latter is often quite easy to obtain, though, since some
resolvers always start their sequence numbers with 0. And the former may be
obtainable via netstat or some analogous host command.

A combined attack on the domain system and the routing mechanisms can be
catastrophic. The intruder can intercept virtually all requests to
translate names to IP addresses, and supply the address of a subverted
machine instead; this would allow the intruder to spy on all traffic, and
build a nice collection of passwords if desired.

For this reason, domain servers are high-value targets; a
sufficiently determined attacker might find it useful to take over a server
by other means, including subverting the machine one is on, or even
physically interfering with its link to the Internet. There is no network
defense against the former, which suggests that domain servers should only
run on highly secure machines; the latter issue may be addressed by using
authentication techniques on domain server responses.

The DNS, even when functioning correctly, can be used for some types of
spying. The normal mode of operation of the DNS is to make specific
queries, and receive specific responses. However, a zone transfer (AXFR)
request exists that can be used to download an entire section of the
database; by applying this recursively, a complete map of the name space can
be produced. Such a database represents a potential security risk; if, for
example, an intruder knows that a particular brand of host or operating
system has a particular vulnerability, that database can be consulted to
find all such targets. Other uses for such a database include espionage; the
number and type of machines in a particular organization, for example, can
give away valuable data about the size of the organization, and hence the
resources committed to a particular project.

Fortunately, the domain system includes an error code for
``refused''; an administrative prohibition against such zone transfers is
explicitly recognized as a legitimate reason for refusal. This code should
be employed for zone transfer requests from any host not known to be a
legitimate secondary server. Unfortunately, there is no authentication
mechanism provided in the AXFR request; source address authentication is the
best that can be done.

Recently, a compatible authentication extension to the DNS has been
devised at M.I.T. The Hesiod name server [34] uses Kerberos [35] tickets to
authenticate queries and responses. The additional information section of
the query carries an encrypted ticket, which includes a session key; this
key, known only to Hesiod and the client, is used to compute a cryptographic
checksum of the both the query and the response. These checksums are also
sent in the additional information field.

5.4 The File Transfer Protocol

The File Transfer Protocol (FTP) [36] itself is not flawed. However, a
few aspects of the implementation merit some care.

5.4.1 FTP Authentication

FTP relies on a login and password combination for authentication.
As noted, simple passwords are increasingly seen as inadequate; more and
more sites are adopting one-time passwords. Nothing in the FTP
specification precludes such an authentication method. It is vital,
however, that the ``331'' response to a USER subcommand be displayed to the
user; this message would presumably contain the challenge. An FTP
implementation that concealed this response could not be used in this mode;
if such implementations are (or become) common, it may be necessary to use a
new reply code to indicate that

- 10 -

the user must see the content of the challenge.

5.4.2 Anonymous FTP

A second problem area is ``anonymous FTP''. While not required by the FTP
specification, anonymous FTP is a treasured part of the oral tradition of
the Internet. Nevertheless, it should be implemented with care.

One part of the problem is the implementation technique chosen. Some
implementations of FTP require creation of a partial replica of the
directory tree; care must be taken to ensure that these files are not
subject to compromise. Nor should they contain any sensitive information,
such as encrypted passwords.

The second problem is that anonymous FTP is truly anonymous; there is no
record of who has requested what information. Mail-based servers will
provide that data; they also provide useful techniques for load-limiting 9 ,
background transfers, etc.

5.5 Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) [37] has recently been
defined to aid in network management. Clearly, access to such a resource
must be heavily protected. The RFC states this, but also allows for a null
authentication service; this is a bad idea. Even a ``read-only'' mode is
dangerous; it may expose the target host to netstat-type attacks if the
particular Management Information Base (MIB) [38] used includes sequence
numbers. (The current standardized version does not; however, the MIB is
explicitly declared to be extensible.)

5.6 Remote Booting

Two sets of protocols are used today to boot diskless workstations
and gateways, Reverse ARP (RARP) [39] with the Trivial File Transfer
Protocol (TFTP) [40] and BOOTP [41] with TFTP. A system being booted is a
tempting target; if one can subvert the boot process, a new kernel with
altered protection mechanisms can be substituted. RARP-based booting is
riskier because it relies on Ethernet like networks, with all the
vulnerabilities adhering thereto. One can achieve a modest improvement in
security by ensuring that the booting machine uses a random number for its
UDP source port; otherwise, an attacker can impersonate the server and send
false DATA packets.

BOOTP adds an additional layer of security by including a 4-byte random
transaction id. This prevents an attacker from generating false replies to
a workstation known to be rebooting. It is vital that these numbers indeed
be random; this can be difficult in a system that is freshly powered up, and
hence with little or no unpredictable state. Care should be taken when
booting through gateways; the more networks traversed, the greater the
opportunity for impersonation.

The greatest measure of protection is that normally, the attacker
has only a single chance; a system being booted does not stay in that state.
If, however, communications between the client and the standard server may
be interrupted, larger-scale attacks may be mounted.

6. TRIVIAL ATTACKS

A few attacks are almost too trivial to mention; nevertheless, completeness
demands that they at least be noted.

__________________

9. Recently, a host was temporarily rendered unusable by massive numbers of
FTP requests for a popular technical report. If this were deliberate, it
would be considered a successful denial of service attack.

- 11 -

6.1 Vulnerability of the Local Network

Some local-area networks, notably the Ethernet networks, are extremely
vulnerable to eavesdropping and host-spoofing. If such networks are used,
physical access must be strictly controlled. It is also unwise to trust any
hosts on such networks if any machine on the network is accessible to
untrusted personnel, unless authentication servers are used.

If the local network uses the Address Resolution Protocol (ARP)
[42] more subtle forms of host-spoofing are possible. In particular, it
becomes trivial to intercept, modify, and forward packets, rather than just
taking over the host's role or simply spying on all traffic.

It is possible to launch denial of service attacks by triggering
broadcast storms. There are a variety of ways to do this; it is quite easy
if most or all of the hosts on the network are acting as gateways. The
attacker can broadcast a packet destined for a non-existent IP address.
Each host, upon receiving it, will attempt to forward it to the proper
destination. This alone will represent a significant amount of traffic, as
each host will generate a broadcast ARP query for the destination. The
attacker can follow up by broadcasting an ARP reply claiming that the
broadcast Ethernet address is the proper way to reach that destination.
Each suspectible host will then not only resend the bogus packet, it will
also receive many more copies of it from the other suspectible hosts on the
network.

6.2 The Trivial File Transfer Protocol

TFTP [40] permits file transfers without any attempt at
authentication. Thus, any publicly-readable file in the entire universe is
accessible. It is the responsibility of the implementor and/or the system
administrator to make that universe as small as possible.

6.3 Reserved Ports

Berkeley-derived TCPs and UDPs have the notion of a ``privileged
port''. That is, port numbers lower than 1024 may only be allocated to
privileged processes. This restriction is used as part of the
authentication mechanism. However, neither the TCP nor the UDP
specifications contain any such concept, nor is such a concept even
meaningful on a single-user computer. Administrators should never rely on
the Berkeley authentication schemes when talking to such machines.

7. COMPREHENSIVE DEFENSES

Thus far, we have described defenses against a variety of
individual attacks. Several techniques are broad-spectrum defenses; they
may be employed to guard against not only these attacks, but many others as
well.

7.1 Authentication

Many of the intrusions described above succeed only because the
target host uses the IP source address for authentication, and assumes it to
be genuine. Unfortunately, there are sufficiently many ways to spoof this
address that such techniques are all but worthless. Put another way, source
address authentication is the equivalent of a file cabinet secured with an
S100 lock; it may reduce the temptation level for more-or-less honest
passers-by, but will do little or nothing to deter anyone even slightly
serious about gaining entry.

Some form of cryptographic authentication is needed. There are
several possible approaches. Perhaps the best-known is the
Needham-Schroeder algorithm [20][21][22] . It relies on each host sharing a
key with an authentication server; a host wishing to establish a connection
obtains a session key from the authentication server and passes a sealed
version along to the destination. At the conclusion of the dialog, each
side is convinced of the identity of the other. Versions of the algorithm
exist for both private-key and public-key [43] cryptosystems.

How do these schemes fit together with TCP/IP? One answer is
obvious: with them, preauthenticated connections can be implemented safely;
without them, they are quite risky. A second answer is that the DNS
provides an ideal base for authentication systems, as it already
incorporates the necessary name structure, redundancy, etc. To be sure, key
distribution responses must be authenticated and/or

- 12 -

encrypted; as noted, the former seems to be necessary in any event.

In some environments, care must be taken to use the session key
to encrypt the entire conversation; if this is not done, an attacker can
take over a connection via the mechanisms described earlier.

7.2 Encryption

Suitable encryption can defend against most of the attacks outlined
above. But encryption devices are expensive, often slow, hard to
administer, and uncommon in the civilian sector. There are different ways
to apply encryption; each has its strengths and weaknesses. A comprehensive
treatment of encryption is beyond the scope of this paper; interested
readers should consult Voydock and Kent [44] or Davies and Price [45] .

Link-level encryption -- encrypting each packet as it leaves the host
computer -- is an excellent method of guarding against disclosure of
information. It also works well against physical intrusions; an attacker
who tapped in to an Ethernet cable, for example, would not be able to inject
spurious packets. Similarly, an intruder who cut the line to a name server
would not be able to impersonate it. The number of entities that share a
given key determines the security of the network; typically, a key
distribution center will allocate keys to each pair of communicating hosts.

Link-level encryption has some weaknesses, however. Broadcast packets
are difficult to secure; in the absence of fast public-key cryptosystems,
the ability to decode an encrypted broadcast implies the ability to send
such a broadcast, impersonating any host on the network. Furthermore,
link-level encryption, by definition, is not end-to-end; security of a
conversation across gateways implies trust in the gateways and assurance
that the full concatenated internet is similarly protected. (This latter
constraint may be enforced administratively, as is done in the military
sector.) If such constraints are not met, tactics such as source-routing
attacks or RIP-spoofing may be employed. Paranoid gateways can be deployed
at the entrance to security domains; these might, for example, block
incoming RIP packets or source-routed packets.

Many portions of the DARPA Internet employ forms of link
encryption. All Defense Data Network (DDN) IMP-to-IMP trunks use DES
encryption, even for non-classified traffic; classified lines use more
secure cryptosystems [46] . These, however, are point-to-point lines, which
are comparatively easy to protect.

A multi-point link encryption device for TCP/IP is the Blacker
Front End (BFE) [47] . The BFE looks to the host like an X.25 DDN
interface, and sits between the host and the actual DDN line. When it
receives a call request packet specifying a new destination, it contacts an
Access Control Center (ACC) for permission, and a Key Distribution Center
(KDC) for cryptographic keys. If the local host is denied permission to
talk to the remote host, an appropriate diagnostic code is returned. A
special ``Emergency Mode'' is available for communications to a restricted
set of destinations at times when the link to the KDC or ACC is not working.

The permission-checking can, to some extent, protect against the DNS attacks
described earlier. Even if a host has been mislead about the proper IP
address for a particular destination, the BFE will ensure that a totally
unauthorized host does not receive sensitive data. That is